Nice work — the implementation is clean and follows the existing middleware conventions well. A few things that aren't covered here that might be worth considering as follow-ups:

Pluggable cache backend — This uses the Web Cache API exclusively, which works great on Deno Deploy but ties caching to the runtime. A storage option (or similar) that accepts a custom backend (Redis, in-memory LRU, etc.) would make this useful in self-hosted/Docker deployments where the Web Cache API may behave differently or not persist across restarts.

CDN cache coordination — For apps behind a CDN (Cloudflare, Fastly, etc.), it's common to need CDN-Cache-Control or Surrogate-Control headers that differ from the client-facing Cache-Control. The middleware could grow a hook for setting upstream cache headers independently, or at minimum the docs could note how to layer CDN headers alongside this middleware.

Vary header awareness — Right now the cache key is the request URL. If a route returns different content based on Accept, Accept-Language, or Accept-Encoding headers (common for i18n or content negotiation), the same URL would serve the wrong cached response. Respecting Vary in the cache key would prevent subtle bugs.

None of these block the initial merge — the current scope is solid and the SWR via queueMicrotask is a nice touch. Just flagging them as potential next steps.